Auto merge of #2385 - alexcrichton:top-level-overrides, r=wycats
authorbors <bors@rust-lang.org>
Thu, 7 Apr 2016 21:17:56 +0000 (14:17 -0700)
committerbors <bors@rust-lang.org>
Thu, 7 Apr 2016 21:17:56 +0000 (14:17 -0700)
commit31214eba27a935933f00702df189e764937d65af
tree1862e8f328d8e7b3ad67155c8fcbb67a600ae682
parentf20ca62a9b43c40e87b2aef004bd25c57eb7fe63
parent54d738b00affacce24375656c966ca3e1efcdc6b
Auto merge of #2385 - alexcrichton:top-level-overrides, r=wycats

Implement top-level overrides

This commit is an implementation of top-level overrides to be encoded into the
manifest itself directly. This style of override is distinct from the existing
`paths` support in `.cargo/config` in two important ways:

* Top level overrides are intended to be checked in and shared amongst all
  developers of a project.
* Top level overrides are reflected in `Cargo.lock`.

The second point is crucially important here as it will ensure that an override
on one machine behaves the same as an override on another machine. This solves
many long-standing problems with `paths`-based overrides which suffer from some
level of nondeterminism as they're not encoded.

From a syntactical point of view, an override looks like:

```toml
[replace]
"libc:0.2.0" = { git = 'https://github.com/my-username/libc';, branch = '0.2-fork' }
```

This declaration indicates that whenever resolution would otherwise encounter
the `libc` package version 0.2.0 from crates.io, it should instead replace it
with the custom git dependency on a specific branch.

The key "libc:0.2.0" here is actually a package id specification which will
allow selecting various components of a graph. For example the same named
package coming from two distinct locations can be selected against, as well as
multiple versions of one crate in a dependency graph. The replacement dependency
has the same syntax as the `[dependencies]` section of Cargo.toml.

One of the major uses of this syntax will be, for example, using a temporary
fork of a crate while the changes are pushed upstream to the original repo. This
will avoid the need to change the intermediate projects immediately, and over
time once fixes have landed upstream the `[replace]` section in a `Cargo.toml`
can be removed.

There are also two crucial restrictions on overrides.

* A crate with the name `foo` can only get overridden with packages also of
  the name `foo`.
* A crate can only get overridden with a crate of the exact same version.

A consequence of these restrictions is that crates.io cannot be used to replace
anything from crates.io. There's only one version of something on crates.io, so
there's nothing else to replace it with (name/version are a unique key).

Closes #942
src/cargo/core/registry.rs
src/cargo/ops/cargo_generate_lockfile.rs
src/cargo/ops/lockfile.rs
src/cargo/ops/resolve.rs
src/cargo/util/toml.rs
tests/tests.rs